Skip to content

Fix mktime: add normalization, O(1) algorithm, and ISO C compliance #316

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Draft
Copilot wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

Fix mktime: add normalization, O(1) algorithm, and ISO C compliance #316

Copilot wants to merge 5 commits into from

Conversation

Copy link

Copilot AI commented Dec 17, 2025 •
edited
Loading

The mktime implementation had three critical issues: (1) out-of-bounds array access with unnormalized month values, (2) missing ISO C required behaviors (tm_wday/tm_yday computation, field normalization), and (3) O(year) time complexity enabling DoS attacks with large year values.

Changes

Normalization

  • Added normalize() function to handle field overflow/underflow before array indexing
  • Prevents out-of-bounds access in MONTH_DAYS[(*t).tm_mon] when tm_mon >= 12
  • Propagates carries correctly: seconds → minutes → hours → days → months → years

ISO C Compliance

  • Implemented calc_wday() using Zeller's congruence for day-of-week computation
  • Implemented calc_yday() for day-of-year computation
  • All tm fields now updated post-normalization per ISO C requirements
  • Handles tm_isdst = -1 for unknown DST status

O(1) Time Complexity

  • Added count_leap_years() using mathematical formula: ⌊y/4⌋ - ⌊y/100⌋ + ⌊y/400⌋
  • Replaced year-by-year loops with direct calculation: days = (year - 1970) × 365 + leap_years + month_days + day
  • Prevents DoS from large year values (e.g., year 10000 now completes instantly)

Example

struct tm t = {
    .tm_year = 124,   // 2024
    .tm_mon = 12,     // Invalid: month 13
    .tm_mday = 32,    // Invalid: day 32
    .tm_sec = 60,     // Invalid: 60 seconds
};

mktime(&t);
// Old: crashes with out-of-bounds access
// New: normalizes to 2025-02-01 00:01:00
//      sets tm_wday=6 (Saturday), tm_yday=31
Original prompt

This section details on the original issue you should resolve

<issue_title>[axlibc] inconsistent mktime behavior with ISO C standard and potential safety issues</issue_title>
<issue_description>The implementation of mktime in arceos/ulib/axlibc/src/mktime.rs is not fully consistent with the ISO C standard and also contains a potential out-of-bounds access issue. Reference for the ISO C standard behavior: https://en.cppreference.com/w/cpp/chrono/c/mktime.

  1. Missing Normalization. The implementation of mktime in arceos/ulib/axlibc/src/mktime.rs does not normalize the input t: *mut ctypes::tm before processing. The ISO C standard permits the tm fields to hold arbitrary values, even values outside their normal ranges. While the ISO standard itself does not define behavior for such cases, POSIX requires mktime to normalize the input to produce a valid result. Another strong reason to fix this problem is that the current implementation can trigger an out-of-bounds memory access. It directly indexes MONTH_DAYS based on (*t).tm_mon, which can exceed 11 when tm_mon >= 12, leading to unsafe memory access.
  2. Missing expected behaviors. According to the ISO C standard, “If the conversion is successful, the time object is modified. All fields of time are updated to fit their proper ranges. time->tm_wday and time->tm_yday are recalculated using information available in other fields.” “A negative value of time->tm_isdst causes mktime to attempt to determine if Daylight Saving Time was in effect.” However, these expected behaviors are currently not implemented.
  3. O(year) time complexity. The current implementation exhibits O(year) time complexity because it computes day offsets year by year. An attacker could supply an excessively large tm_year value, causing the application program to hang or severely degrade performance.</issue_description>

Comments on the Issue (you are @copilot in this section)

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Copilot AI and others added 4 commits December 17, 2025 14:33
@equation314
Fix mktime implementation: add normalization, O(1) algorithm, and upd…
0320531 
…ate tm fields

Co-authored-by: equation314 <11389231+equation314@users.noreply.github.com>
@equation314
Add comprehensive test documentation for mktime fixes
1aa8236 
Co-authored-by: equation314 <11389231+equation314@users.noreply.github.com>
@equation314
Address code review feedback: improve Zeller's formula and clarify tm…
6efa2ee 
…_isdst handling

Co-authored-by: equation314 <11389231+equation314@users.noreply.github.com>
@equation314
Fix mktime: add normalization, O(1) algorithm, and ISO C compliance
0d38df7 
Co-authored-by: equation314 <11389231+equation314@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix inconsistent mktime behavior with ISO C standard Fix mktime: add normalization, O(1) algorithm, and ISO C compliance Dec 17, 2025
Copilot AI requested a review from equation314 December 17, 2025 14:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@equation314 equation314 Awaiting requested review from equation314

At least 1 approving review is required to merge this pull request.

Assignees

@equation314 equation314

Copilot code review Copilot

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[axlibc] inconsistent mktime behavior with ISO C standard and potential safety issues

2 participants

@equation314